Skip to content

fix: fixes debug_traceBlockByNumber response to not be null for a transaction with no internal calls #4440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

fix: fixes debug_traceBlockByNumber response to not be null for a transaction with no internal calls #4440

wants to merge 3 commits into from
+23 −11

Conversation

simzzz
Copy link
Contributor

@simzzz simzzz commented Oct 2, 2025 •
edited
Loading

Description

When calling debug_traceBlockByNumber for a block, and some transaction from the block hasn't made any calls, then null would be returned for that transaction. The result should be the root call object with an empty calls array instead of null. We build the root object from the same fields in the transaction object that would back the root call: from, to, value, gas, gasUsed, input, output/error (from transactionsResponse) and calls: [].

  • When actions are present, we use actionsResponse[0].call_type for type. When actions are absent, we infer type as "CALL" if to exists, otherwise "CREATE". Everything else matches the root call data.

Related issue(s)

Fixes #4386

Testing Guide

  1. Call debug_traceBlockByNumber for a block that contains a transaction with no calls
  2. Make sure result is an object with an empty calls array instead of null

Changes from original design (optional)

N/A

Additional work needed (optional)

N/A

Checklist

  • I've assigned an assignee to this PR and related issue(s) (if applicable)
  • I've assigned a label to this PR and related issue(s) (if applicable)
  • I've assigned a milestone to this PR and related issue(s) (if applicable)
  • I've updated documentation (code comments, README, etc. if applicable)
  • I've done sufficient testing (unit, integration, etc.)

@simzzz simzzz added this to the 0.73.0 milestone Oct 2, 2025
@simzzz simzzz self-assigned this Oct 2, 2025
@simzzz simzzz added the bug Something isn't working label Oct 2, 2025
@simzzz simzzz changed the title fix: fixes response to not be null when no calls fix: fixes debug_traceBlockByNumber response to not be null for a transaction with no internal calls Oct 2, 2025
@github-actions GitHub Actions
Copy link

github-actions bot commented Oct 2, 2025 •
edited
Loading

Test Results

 20 files  ±0  265 suites  ±0   20m 40s ⏱️ -51s
764 tests ±0  737 ✅  - 21  4 💤 ±0  23 ❌ +21 
780 runs  ±0  753 ✅  - 21  4 💤 ±0  23 ❌ +21 

For more details on these failures, see this check.

Results for commit 510bc1a. ± Comparison against base commit 533a976.

♻️ This comment has been updated with latest results.

@simzzz simzzz marked this pull request as ready for review October 2, 2025 13:51
@simzzz simzzz requested review from a team as code owners October 2, 2025 13:51
@simzzz simzzz requested a review from Ferparishuertas October 2, 2025 13:51
@quiet-node
Copy link
Contributor

quiet-node commented Oct 9, 2025 •
edited
Loading

I can't seem to reproduce this issue. Block 0x5067CB1 (mentioned in the associated ticket) contains two EthereumTransaction entries, one failed due to a wrong nonce and one succeeded. Using your updated version in this PR and the main branch (without this update), running debug_traceBlockByNumber with that block as a parameter returns a non-null response in both cases:

{
    "result": [
        {
            "txHash": "0xa74c140aedec484c5c6cb559aecd75386d15cbafcc3e55c90d5302adbea86337",
            "result": {
                "type": "CALL",
                "from": "0x339d413ccefd986b1b3647a9cfa9cbbe70a30749",
                "to": "0x3c2269811836af69497e5f486a85d7316753cf62",
                "value": "0x0",
                "gas": "0xaae60",
                "gasUsed": "0x88b80",
                "input": "0x3161b7f600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000016f000000000000000000000000000000000000000000000000000002109014be420000000000000000000000000000000000000000000000000000000005f86e6b0000000000000000000000000000000000000000000000000000000000000010",
                "output": "0x",
                "calls": [
                    {
                        "type": "DELEGATECALL",
                        "from": "0x3c2269811836af69497e5f486a85d7316753cf62",
                        "to": "0x4ee2f9b7cf3a68966c370f3eb2c16613d3235245",
                        "gas": "0xa1b93",
                        "gasUsed": "0x2a78",
                        "input": "0x3161b7f600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000016f000000000000000000000000000000000000000000000000000002109014be420000000000000000000000000000000000000000000000000000000005f86e6b0000000000000000000000000000000000000000000000000000000000000010",
                        "output": "0x",
                        "value": "0x0"
                    }
                ]
            }
        }
    ],
    "jsonrpc": "2.0",
    "id": 1
}

Am I missing something or it's just too late to use that block now?

@quiet-node
Copy link
Contributor

Couple of questions left on the associated ticket as well #4386 (comment)

@simzzz
Copy link
Contributor Author

simzzz commented Oct 15, 2025

@quiet-node hmm, I also can't reproduce it along with other examples I had written down. (perhaps it was a bug on MN side due to modularization, that is now fixed?). Nevertheless, I still think we should fix the response format for this particular case. I will try to find another example.

@quiet-node
Copy link
Contributor

@quiet-node hmm, I also can't reproduce it along with other examples I had written down. (perhaps it was a bug on MN side due to modularization, that is now fixed?). Nevertheless, I still think we should fix the response format for this particular case. I will try to find another example.

Yeah let's bring this up to a parking lot session and discuss as a team

@codecov Codecov
Copy link

codecov bot commented Oct 20, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff             @@
##             main    #4440      +/-   ##
==========================================
- Coverage   96.23%   96.22%   -0.01%     
==========================================
  Files         121      121              
  Lines       20001    19998       -3     
  Branches     1755     1750       -5     
==========================================
- Hits        19247    19244       -3     
  Misses        735      735              
  Partials       19       19
Flag Coverage Δ
config-service 98.80% <ø> (ø)
relay 91.17% <75.00%> (-0.01%) ⬇️
server 88.85% <ø> (ø)
ws-server 98.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
packages/relay/src/lib/debug.ts 99.37% <100.00%> (-0.01%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Ferparishuertas Ferparishuertas Awaiting requested review from Ferparishuertas Ferparishuertas is a code owner automatically assigned from hiero-ledger/hiero-json-rpc-relay-maintainers

At least 2 approving reviews are required to merge this pull request.

Assignees

@simzzz simzzz

Labels

bug Something isn't working

Projects

None yet

Milestone

0.73.0

Development

Successfully merging this pull request may close these issues.

Wrong response when calling debug_traceBlockByNumber and a transaction from the block doesn't contain any calls

2 participants

@simzzz @quiet-node